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ABSTRACT 

This paper presents the ESA concept 
for the use of CCSDS defined Teleme- 
try and Telecommand Packets at the 
application level. These Packets are 
used to monitor and control remotely 
a spaceborn application. This concept 
is defined in a Packet Utilisation 
Standard (PUS) which should become 
applicable for all ESA missions using 
Packets. The production of this stan- 
dard is under the responsibility of 
an ESA standardisation group called 
"COES" . 

Keywords: Packet Utilisation, Packet 
Type, Parameter, Packet Structure, 
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1. INTRODUCTION 

The usual way to monitor a space- 
craft, is to get parameters via the 
Time Division Multiplexed Telemetry. 
Similarly the control function is 
performed by telecommand frames con- 
taining basic instructions to the 
spacecraft. This constitutes actually 
a remote monitoring and control of 
on-board electronics. 

However, on-board software is used 
more and more to address specialised 
complex functions which could other- 
wise hardly be operated from ground. 

Up to now, because of no other 
choice, on-board software is remotely 
monitored and controlled using the 
classical electronic oriented samp- 
ling mechanism and bus commands. 
Rapidly it became clear that this 
imposes heavy constraints on the on- 
board software implementation, limi- 
ting its flexibility and consequently 
hampers the trend towards more on- 
board intelligence and autonomy. 

In order to overcome this situation, 
the Consultative Committee for Space 
Data Systems (CCSDS) recommended the 


use of Telemetry ( TLM ) and Telecom- 
mand (TLC) Packets and specified 
precisely how such Packets should be 
transmitted between space and ground. 
Those Packets will mostly contain 
software data of which structure and 
format will have a significant impact 
on the software architecture on 
board, but also on ground. 

However, making things more flexible 
leads to the possibility of implemen- 
ting a given control function in many 
different ways. Anticipating this 
potential problem, ESA decide^ to 
address this point in one standar- 
disation committee (COES) and to 
produce a Packet Utilisation Standard 
which recommends to users of Packets 
general rules governing the exchange 
of Packets between space and ground, 
as well as the data structure and 
format to be used within the Packets. 
It also recommends specific Packets 
for specific but commonly used func- 
tions. 

This standard should also enable the 
implementation of a clean software 
architecture on board and on ground 
much more adapted to on-board intel- 
ligence and autonomy. 


2. PROBLEM CAUSED BY THE USE 
OF PACKETS 

Until a few years ago, satellites had 
only limited on-board processing 
capabilities. The Telemetry was es- 
sential on-board device digital read- 
outs (e.g. sensors, switches, payload 
hardware etc. ) sampled at fixed regu- 
lar intervals and multiplexed at 
fixed positions in a telemetry frame. 
Similarly the Telecommand contained 
fixed length data words which were 
supposed to load on-board registers 
(for a specific device) or to enable/ 
disable switches. With this technique 
it was possible from ground to moni- 
tor and control remotely on-board 
devices (Fig. 1 ) . However, the as- 
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sociated space-ground communication 
technique of the Telemetry and Tele- 
command data did not guaranty a safe 
and complete transmission of data. 



With the advent of more complex on- 
board processors and thus software, 
the need arose to exchange data of a 
different nature (generated by soft- 
ware) between space and ground which 
requires a more flexible transmission 
capability (e.g. variable content, 
asynchronous generation) and conse- 
quently a transmission technique of 
better quality (e.g. error-free and 
complete) . In fact, one does not 
control on-board devices directly but 
rather through on-board software. 
What was needed is a technique to 
enable a remote monitoring and con- 
trol of on-board software (Fig, 2). 



Fig. 2 : Remote Control of an Application 


The Consultative Committee for Space 
Data Systems (CCSDS) has defined and 
recommended the use of Telemetry 
Packets (Ref. 4) and Telecommand 
Packets (Ref. 5) which is a space- 


ground high quality communication 
technique enabling a flexible ex- 
change of data between an on-board 
Application (usually software) and a 
ground system (also software) . How- 
ever, nothing is said on the content 
of these Packets and according to 
which principle they should be ex- 
changed . 

This is now the key problem. Since 
this aspect will largely determine 
the system architecture on board and 
on ground and also to some extent the 
functionality, it will not be pos- 
sible to achieve common infrastruc- 
tures (e.g. ground control centres ) 
reusable for different missions, in 
absence of recommendations on the 
content of Packets and the way they 
are exchanged . 


3. ROLE OF THE C.O.E.S. 

STANDARDISATION GROUP 

In 1987 an intra-agency standardisa- 
tion group was created; the Committee 
for Operation and EGSE standardisa- 
tion ( COES ) . The objectives were to 
define and specify the common func- 
tions between a satellite checkout 
system (EGSE) and a satellite control 
system. Even if these systems are 
used for a different objective in a 
different project phase, a large 
amount of functions are similar and 
the logical interface to the satel- 
lite is identical . Therefore, a com- 
mon system could be used for the 
checkout and operation within a given 
project (vertical commonality) but 
also across projects (horizontal 
commonality) . 

It was also decided to define such a 
common system for missions using the 
newly defined Telemetry and Telecom- 
mand Packets. It became rapidly clear 
that this task was only feasible if a 
clear satellite-ground interface is 
specified, based on the use of Pack- 
ets (Fig. 3) . 

Consequently, the first task of the 
COES was to produce a standard which 
defines precisely the use of Packets 
from an application viewpoint. Such a 
document (Packet Utilisation Standard 
STD-07-101 ) has been produced by the 
COES and is presently undergoing an 
Agency-wide review . 
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Fig. 3 : Checkout / Operation System Commonality 


4. SCOPE OF THE STANDARDISATION 

The Packet Utilisation Standard (Ref. 

1 ) serves to complement and extend 
the Packet Telemetry Standard (Ref. 

2) and the Packet Telecommand stan- 
dard (Ref. 3), in order to satisfy 
the requirements of electrical in- 
tegration and testing and flight 
operations. The term Utilisation is 
used to cover all what should be 
known around Packets (e.g. their 
content, how it is generated, which 
functionality they convey, etc.) in 
order to operate a remote Applica- 
tion. 

An Application is an on-board logical 
entity which generates Telemetry 
Packets and also receives Telecommand 
Packets for the purpose of monitoring 
and controlling the Application. The 
Application is identified by an Ap- 
plication ID used to establish an 
end-to-end connection between this 
Application and the Ground. An Ap- 
plication can be any (or part of) 
platform of payload subsystem. 

The standard is an interface document 
defining the relationship between 
space and ground. It, therefore, 
contains : 

- requirements relating to satellite 
monitoring and control functions 
and to testability; 

- Telemetry and Telecommand Packet 
types and sub- types (depending on 
the functionality) ; 

- Packet data structures and format. 

To the maximum extent, this standard 
utilises techniques emerging from 
modern software engineering trends. 


This standard is in principle appli- 
cable to the full variety of mission 
classes, ranging from a satellite of 
relatively simple on-board design in 
an orbit with continuous ground co- 
verage like a geostationary communi- 
cation satellite, to a more complex 
mission like a low-earth orbiting 
scientific satellite or a deep-space 
mission. 

The three principal driving factors 
which place the strongest demand on 
Telemetry and Telecommand are the 
degree of on-board complexity, the 
degree of on-board autonomy (these 
two factors being inter-related) and 
the link transmission capacity. 

5. OPERATIONAL REQUIREMENTS 

Telemetry and Telecommands must be 
provided to enable the safe and reli- 
able execution of all nominal and 
contingency operations which are 
required to achieve the mission ob- 
jectives . 

The general principles of the opera- 
tions model are as follows: 

- Nominal operations 

The Application generates the 
relevant housekeeping information 
(depending on the mission phase) 
either whenever a significant 
event occurred on-board or at 
regular intervals. 

In the former case this informa- 
tion may also be generated on 
request by the ground. The infor- 
mation is composed of a suite of 
parameters (e.g. on-board varia- 
bles, indirect device read-outs 
etc . ) . 

The Application generates infor- 
mation reports to indicate special 
events and any actions taken auto- 
nomously by the on-board system. 

On reception of a Telecommand the 
Application responds systematical- 
ly on the validity status of it, 
and execution progress until com- 
pletion. 

When accurate parameter time cor- 
relation is required, this is 
achieved either by associating 
explicitly a time-tag with the 
parameter or by reconstructing of 
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the time on ground from the Packet 
time with implicit knowledge of 
the on-board "sampling" mechanism 
used. 

- Contingency operations 

The Application has a diagnostic 
mode which enables to investigate 
short timescale phenomena of tran- 
sient effects. 

The Application logic may be modi- 
fied or reprogrammed from ground 
in case of malfunctioning. 

The Application may also be opera- 
ted in an off-line manner in order 
to check its correct functionality 
before switching it to the opera- 
tional mode. 

Any Application protection logic 
may be disabled from Ground and 
thus overruled. 


All Packet contents (the Packet data 
field) are composed of fields (here 
called parameters) coded according to 
standard formats and organised accor- 
ding to a standard structure. 

For well-defined monitoring and con- 
trol functions, specialised Packets 
are defined, to which specific (PT, 
PST) pairs have been assigned, and 
which Packet content conforms to the 
general rules. Of course, those Pack- 
ets are mandatory only if these func- 
tions are needed. 

However, growth capability of the 
standard is ensured by expanding it 
with the introduction of new function 
categories or new subfunctions within 
an existing function category. 

The presently defined categories of 
Packets are shown in Table 1 and 
Table 2. 


6. PACKET TYPE AND SUBTYPE 

For a given Application, the infor- 
mation contained in a Packet may 
correspond to different functionali- 
ty. This is identifiable from the 
Packet Data Field Header (PDFH) which 
has a fixed structure for Telemetry 
and for Telecommand (Fig. 4). 


/ 




... 

.PACKEJ-.-,- 

/type// 

>>CK£T\*t 
. SUBTYPE*. \ 

ill 


fi bits 

B bits 

a t>tt* 

5 bits 

Telecomna 

na Packet De 

to 

ader 


/PACKET.;.;. 

/racket.;.;. 

-SuBTyw"'-' 


!ac£\; 








64 bits 

a bits 

8 bits 

3 blti 

5 bits 

Telemetry Packet Data header 

V _ ... J 


Fig. 4 : Packet Data Field Header 


The two most important fields in the 
PDFH are the Packet Type (PT) and the 
Packet Subtype (PST). The PT iden- 
tifies the higher level of a Packet 
category whereas the PST identifies a 
lower level within this category. The 
couple (PT, PST) has a unique defini- 
tion and applies across different 
Applications. 




Type 

PT 

Sub Type 
PST 

FUNCT ION 

1 

1 

Device Command 

2 

1 ... 5 

Control Process 

3 

1 

Software Command 

4 

1,2, 3 

Load Memory 

5 

1,2/3 

D ump Memor y 

6 

1,2 

Di agnost i c 

7 

1 . . .. 7 
11 ... 17 

Telemetry Generation 

8 

1 ... 12 

Master Schedu 1 e 

9 

v_ .... 

1 ... 9 

On-Board Mon i tor i ng 

J 


Table 1 : List of Defined Telecommand Packets 
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Type 

PT 

Sub Type 
PST 

. ... . 

NATURE 

1 

1 

Housekeep i ng 

2 


Report 

3 

1 

TC Ver i f i cat i on 

A 

1 

Ti me 

5 

1,2,3 

Memory Dump 

6 

1,2 

i 

D i agno.st 1 c 

7 


C Not def i ned} 

8 

i 

Master Sc-hedu 1 e 

9 



1,2, 3 

On-Board Mon i tor i ng 

) 


Table 2 : List of Defined Telemetry Packets 


1 . PACKET STRUCTURE AND FORMATS 

The structures and formats adopted 
for this standard are oriented to- 
wards modern software language (e.g. 
Pascal, C, C ++ , ADA) data structures. 
Thus they can be handled conveniently 
by the on-board or ground software, 
and offer the required flexibility. 
The interpretation of the Packet 
requires an implicit knowledge of the 
Packet content by the application 
supposed to process it. This is a- 
chieved by specific in-line coding 
(e.g. data statements) or better by 
an on-line interpretation of data 
description tables. The description 
information refers to Parameter Names 
(like variable names in a programme) 
which associates the Parameter Type, 
the position within the structure, 
and its interpretation (e.g. unit, 
calibration, scaling, attached proce- 
dure etc . ) . 

The Parameter Type defines a class of 
encoding of the parameter value. For 
a given Parameter Type there are 


possible variations in the length of 
the value encoding. The only Parame- 
ter Types allowable for Telemetry and 
Telecommand parameters are those 
listed in Table 3. 


; PApM<trr £*:■:■ 

x-we-x-x 

LENGTH 

*v 

DEFINITION 

Boolean 

1 bit 

0 * False , 1 = True ! 

Logica i 

8/16 bits 

Used in logical operations 

1 nteger 

1 / 2 / 4 / 8 octets 

Signed or uns igned C 1 50} 

Rea) 

2/ 4/ 6/ 8 octets 

Cl SO} 

Str i ng 

0 - 255 octets 

ASCII CiSCT) character string 

Time 

1 - B octets 

■ . ... . - __j 

CCSOS time CCUC or CDS} 

Address 

2/4 octets 

Offset, base or offset ♦ base 


Table 3 : List of Parameter Types 


A Record is a logical grouping of 
different Parameters or Arrays or 
other Records. An Array contains 
several instances of the same Record. 
By this definition the Packet Data 
Field is a Record. Consequently there 
could be several levels of nesting of 
Arrays and Records, although this 
flexibility should not be abused. 

An Array can either be a Fixed-Array 
of a fixed number of instances (known 
implicitly by the application accor- 
ding the structure definition) or be 
a Variable- Array of a variable number 
of instances indicated in front of 
the Array. The structuration rules 
are presented in a "syntax diagram" 
form on Figure 5, 
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8. VALIDATION 


Before approving this standard, and 
before implementing supporting infra- 
structures, it was necessary to en- 
sure its correctness, its practicabi- 
lity and operational usefulness. This 
has been achieved by a prototyping 
exercise completed in early 1992, 
which has validated the standard and 
at the same time given some indica- 
tion on the implementation technique. 


The Packet communication technique 
has not been addressed in this proto- 
type since this is already demonstra- 
ted. Rather the application end-to- 
end aspect was implemented, emulating 
the Spacecraft Application behaviour 
in relationship to the Ground Appli- 
cation (e.g. control system) in con- 
trol of it. 

This prototype (called PUSV) runs on 
one or two SPARC workstations and 
permits at the same time to model 
different on-board Application ar- 
chitectures. A reference satellite 
model (called PUSSAT) was implemented 
for demonstration purposes. 


9. FUTURE PERSPECTIVES 

The PUS draft standard will be re- 
viewed at Agency level and it is 
expected that it will become an Agen- 
cy approved standard in the first 
half of 1993. 

Furthermore, this standard is expec- 
ted to evolve in the future in an 
incremental way when some commonly 
used monitoring and control functions 
are mature enough to be generalised 
and thus standardised. 

ESA plans to develop the necessary 
ground infrastructures (e.g. mission 
control kernel system) to support 
this standard but also more generally 
the operational functions of such a 
system in order to achieve in reality 
the vertical and horizontal commona- 
lity of a generic system to be used 
for checkout and operation across 
different projects. 
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